RocketMQ|解耦、异步、削峰原理解析

前言

开门见山的说，MQ肯定是有用的，不然这么多人用它干嘛(当然可能有人觉得可以装逼用2333）

不过这次我们要说的RocketMQ可不是美国进口的技术，是阿里巴巴捐赠给apache，让apache孵化用的。

RocketMQ提供at least once的语义，消息不会丢，但是有可能重复，业务上如果对重复接受度低的话，需要在业务层面规避重复带来的影响，比如去重或者幂等

阿里巴巴官方给出的RocketMQ的特点

• 是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。
• Producer、Consumer、队列都可以分布式。
• Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合。
• 能够保证严格的消息顺序
• 提供丰富的消息拉取模式
• 高效的订阅者水平扩展能力
• 实时的消息订阅机制
• 亿级消息堆积能力
• 较少的依赖

先说说MQ的作用：

• 解耦
  假如现在两个系统，当B系统crash掉，A系统也就凉了，这就是耦合带来的问题。
  
  假如我现在用消息队列，就是这样子的。
  
  即使B系统crash，A系统照常运行，A只需要把消息给到消息队列就可以。
• 异步
  假如现在有这么个业务场景，分别有三个系统，用户支付成功后，支付系统调用生成订单系统来生成订单，再继续调用通知用户业务系统，最后返回给支付系统，是不是支付系统要等半天？

用户就想了，我tm等半天才能下个单，以后不在你这买了，这就损失了一名客户

加上消息队列会咋样？

依然是一个链式调用，不同的是，这次支付系统把任务信息告诉消息队列就可以了，剩下的事情，他就不管了，而是又消息队列和其他系统合作去完成。

• 削峰
  RocketMQ可是阿里巴巴拿来抗双十一的中间件，你说刚不刚？

我们都知道，如果同时给服务器本不该承受的压力，它就会宕机。

而消息队列在削峰方面的思想就是，把大量的订单都放到消息队列里，挨个去处理，这样的结果可能是有的用户下单要等的久一些才能成功，但是好处就在于服
务器不会凉凉鸭，如果凉了，还卖啥？

一、 RocketMQ的组成

• Message : 消息

• Broker: RocketMQ的核心模块，负责接收并存储消息。

• NameServer: RocketMQ的注册中心，集群的Topic-Queue的路由配置；Broker的实时配置信息。其它模块通过Nameservr提供的接口获取最新的Topic配置和路由信息。

• Topic ：用于将消息按主题做划分，Producer将消息发往指定的Topic，Consumer订阅该Topic就可以收到这条消息。Topic跟发送方和消费方都没有强关联关系，发送方可以同时往多个Topic投放消息，消费方也可以订阅多个Topic的消息。在RocketMQ中，Topic是一个上逻辑概念。消息存储不会按Topic分开。

• Tag： 标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息，Tag也可以对消息进行快速的过滤，例如后面consumer在subscribe的时候可指定tag，如果不需要过滤，设置为*即可。

• Producer：消息的生产者

• Consumer：消息的消费者

二、RocketMQ的整体架构

从上面抽象来看，RocketMQ的原理在于：

• 生产者将消息给到队列(Broker)
• 队列中的消息在逻辑上是以Topic来分类的，进一步还可以通过Tag来过滤
• 消费者消费消息
  

从下面这个图，可以看到Rocket MQ天生就是分布式的，Broker作为存储消息的核心组件，支持主从机制，一个挂了，我还有备用呢。

无论是Broker还是Name Server 都可以做分布式，从而让整个系统变得高可用

• 每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
• Producer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息。
• Consumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息。

三、RocketMQ有序消息

实现顺序消费消息，需要把这些消息放到同一个queue中，所以需要指定相同的partition key

并设置orderly=true

乱序现象

• 双机房容灾：容灾切换的时候，会切换机房，故障恢复后，会消费故障出现前的数据，此时无法保证有序
• 扩容：扩容会导致queue增加，导致不同queue中可能出现相同的key，不能保证有序性

参考

https://www.cnblogs.com/qdhxhz/p/11094624.html
http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/

本人水平有限，希望各位不吝赐教。